
Im Jahr 2009 beschloss ein Mitglied des chinesischen Politbüros, herauszufinden, was das Internet über ihn gesammelt hatte. Er suchte seinen eigenen Namen bei Google und wurde, nun ja, äußerst wütend, als er die Ergebnisse durchsah. Rache war die einzige Antwort.
Kurz darauf gelang es einer chinesischen Advanced Persistent Threat-Gruppe (APT) namens Elderwood Group, das Unternehmensnetzwerk von Google zu kompromittieren. Die Gruppe entwendete eine Menge geistigen Eigentums und versuchte, sich Zugang zu E-Mail-Konten von Menschenrechtsaktivisten zu verschaffen. Agenten des Staatssicherheitsdienstes untersuchten das Bankkonto eines Zielobjekts. Infolgedessen änderte Google seine Haltung gegenüber google.cn. Es würde die Zensur von Suchergebnissen einstellen; sollte sich herausstellen, dass eine unzensierte Suchmaschine gegen das Gesetz verstößt, würde sie das Land vollständig verlassen. Besucher des Google-Hauptsitzes in Peking legten Blumen auf das Schild, die als „illegale Blumengabe“ deklariert und gereizt entfernt wurden.
Ich möchte darauf hinweisen, dass Google nicht das einzige Opfer war. Bei einer Aktion mit dem Namen Operation Aurora nahmen die Angreifer mindestens 20 weitere große Unternehmen ins Visier, indem sie Sicherheitslücken im Internet Explorer (seufz) und einem Versionskontrollsystem namens Perforce ausnutzten. Das Hauptziel war der Zugriff auf und die Modifizierung von Quellcode-Repositorys bei verschiedenen Technologie- und Verteidigungsunternehmen. Erstaunlicherweise hatte niemand daran gedacht, diese weit geöffneten Behälter mit wertvollem geistigem Eigentum zu sichern! Die kompromittierten Systeme stellten über gestohlene virtuelle Maschinen von Rackspace-Kunden ausgehende TLS-Verbindungen zu Command-and-Control-Servern (C&C) in Illinois, Texas und Taiwan her. Sie untersuchten verbundene Netzwerke, um Repositorys und andere anfällige Systeme zu finden.
Von 2014 bis 2018 hat Google seine Zugangsarchitektur neu gestaltet, um solche Angriffe in Zukunft abzuwehren. Alle Mitarbeiter wurden in ein unprivilegiertes Netzwerk verlagert, auch die Mitarbeiter in den Google-Büros. Sie befinden sich im Wesentlichen „außerhalb“ des Unternehmensnetzwerks und erhalten nur Internetverbindungen. Sämtlicher Zugriff – ob von dort oder von einem anderen Netzwerk – erfolgt über einen identitätsbewussten Zugriffsproxy. Es existiert kein klassischer Netzwerk-Perimeter. Google kam zu dem Schluss, dass Unternehmensnetzwerke nicht weniger gefährlich sind als das öffentliche Internet und dass es unaufrichtig ist, an der Illusion festzuhalten, dass sie es jemals gewesen wären.
Formal dokumentiert und als BeyondCorp implementiert, hängt der Zugriff ausschließlich von den Benutzerdaten und dem Gerätestatus ab (BeyondCorp erlaubt nur verwaltete Geräte und erfordert 802.1X und PKI). Es harmonisiert die Art und Weise, wie Menschen auf Anwendungen und Daten zugreifen, unabhängig davon, wo sie sich befinden und welche Netzwerke sie nutzen – es gibt keine Unterscheidung mehr zwischen lokalem Zugriff und Fernzugriff.
ZTNA kündigt sein Erscheinen an
Ein Jahr später, 2019, veröffentlichte Gartner seinen ersten „Marktleitfaden für Zero Trust Network Access“ (ich war damals als Gartner-Analyst Hauptautor). Darin wurden zwei Stile identifiziert:
- Endpoint-initiiert spiegelte eine ältere Spezifikation für softwaredefinierte Perimeter wider und war ausschließlich für lokalen Zugriff vorgesehen; es gab eine Liste erlaubter Anwendungen zurück, nachdem sich eine Person authentifiziert hatte.
- ZTNA Service-Initiierung folgte teilweise dem Design von BeyondCorp, bei dem Benutzer und Geräte als „remote“ betrachtet wurden, selbst wenn sie sich im selben Gebäude befanden. Die Anforderungen für verwaltete Geräte, 802.1X und PKI wurden aufgehoben. Es fügte eine Besonderheit hinzu: Verbindungen von innen nach außen.
Mehrere Cloud-basierte Startups haben das Modell der Service-Initiierung übernommen, da es sich besser für den Fernzugriff eignet. Ein Konnektor startet eine ausgehende Sitzung zum Broker in der Cloud des Anbieters – also „von innen nach außen“. Der Broker schützt Anwendungen vor Entdeckung im Internet und schränkt seitliche Bewegungen ein.
Jedoch haben die Anbieter nur Szenarien für den Fernzugriff in Betracht gezogen. Es schien, als sei die BeyondCorp-Lektion vergessen worden.
ZTNA wird universell
In letzter Zeit haben einige Anbieter – darunter auch Netskope – ihre ZTNA-Dienste um lokale Broker vor Ort erweitert. Dies hat den Spitznamen „Universal ZTNA“ erhalten und stimmt interessanterweise enger mit der BeyondCorp-Philosophie überein. Wir können beobachten, dass Google eine Zugriffsarchitektur aufgebaut hat, die sehr stark an ZTNA erinnert – bevor ZTNA ein Begriff war.
Betrachten wir ZTNA anhand der Begriffe von Netskope. In Ihrem Rechenzentrum oder Ihrer IaaS-Cloud baut ein dort konfigurierter Publisher eine dauerhafte ausgehende Sitzung zum Publisher-Gateway-Teil des privaten Zugriffsbrokers in unserer Cloud auf. Wenn eine Remote-Person auf eine veröffentlichte Ressource zugreifen möchte, stellt sie wie gewohnt eine Verbindung her, die tatsächlich mit einer Sitzung zum Client-Gateway-Teil des privaten Zugriffsbrokers beginnt. Wir fügen diese Sitzungen zusammen, und es entsteht eine Aktivität. Wir nennen das jetzt Remote-ZTNA, weil die Personen „remote“ bezüglich der Anwendung sind.
Für den lokalen Zugriff platziert das lokale ZTNA einen Broker im selben Netzwerk wie die Ressourcen, mit denen die Benutzer interagieren möchten. In den meisten Fällen befinden sich die Personen am selben physischen Ort wie das Rechenzentrum. Publisher stellen Sitzungen mit dem lokalen Broker her, und wenn sich eine Person mit einer Ressource verbindet, fließt der Datenverkehr über den lokalen Broker und nicht über den in unserer Cloud.

Warum ein lokaler Broker? Erinnern Sie sich an das Hairpinning-Problem: Wenn Remote-Mitarbeiter über ein lokales Rechenzentrum auf Internetressourcen zugreifen müssen, beeinträchtigt dies die Leistung. Ähnlich verhält es sich mit dem umgekehrten Hairpinning: Wenn lokale Nutzer gezwungen werden, über einen Cloud-basierten Broker auf lokale Ressourcen zuzugreifen, leidet die Performance ebenfalls. Lokaler Datenverkehr sollte lokal bleiben.
Universal ZTNA kombiniert Remote-ZTNA mit lokalem ZTNA und repräsentiert das Beste von BeyondCorp. Es:
- Vereinheitlicht das Zugriffserlebnis, sodass die Benutzer nicht mehr darüber nachdenken müssen, wie sie auf Anwendungen zugreifen können. Unser Ziel ist es stets, Menschen dabei zu helfen, das richtige Gleichgewicht zwischen Sicherheit und Arbeitsausführung zu finden. Wenn wir von ihnen erwarten, mehrere Remote-Zugriffsmethoden zu verwenden, die sich alle vom lokalen Zugriff unterscheiden, könnten sie sehr wohl das Risiko erhöhen, indem sie unsichere Workarounds erfinden. Wir sollten nicht erwarten, dass unsere Leute an der Infrastruktur herumbasteln, um ihre Arbeit zu erledigen. Universal ZTNA beseitigt alle Hindernisse im Zusammenhang mit dem Zugriff und bietet eine einzige, konsistente und sichere Methode, die unabhängig davon funktioniert, wo sich Personen oder Anwendungen befinden.
- Beseitigt privilegierte Netzwerke, die in Wirklichkeit nicht sicherer sind als das Internet. Traditionelle Zugriffsmethoden in privilegierte Netzwerke stellen weiterhin ein Risiko für diese Netzwerke dar, sei es durch kompromittierte Hosts (Ransomware) oder durch kompromittierte Personen (Privilegienausweitung). Ich würde argumentieren, dass universelles ZTNA die Notwendigkeit der Aufrechterhaltung privilegierter Netzwerke beseitigt, da IP-basiertes Routing entfällt. (U)ZTNA verbindet Menschen mit Daten, nicht Geräte mit Netzwerken. [Hinweis: In diesem Blogbeitrag verwende ich „(U)ZTNA“, um anzuzeigen, dass eine zugehörige Beobachtung sowohl für „reguläres“ ZTNA als auch für universelles ZTNA gilt.] Bevor die Personenseite der Inside-Out-Verbindung mit der Publisherseite verknüpft wird, muss sich die Person erfolgreich beim Unternehmensverzeichnis eines Unternehmens authentifizieren. Dieses Paradigma „Erst authentifizieren, dann verbinden“ ist die sichere Alternative zum Standard „Erst verbinden, dann authentifizieren“, der seit seiner Einführung in den 1970er Jahren nicht mehr sicher ist. Bei diesem Standard kann nichts entschlossene Angreifer daran hindern, alle Arten von bösartigem Datenverkehr auf unschuldige Listening-Sockets hinter Lücken in Firewalls zu schleudern.
- Beseitigt herkömmliche VPNs, einen anhaltend und schmerzlich anfälligen Einstiegspunkt. VPNs sind eine Technologie aus den 1990er Jahren, die ursprünglich für kleine Personengruppen entwickelt wurde, die Router aus der Ferne verwalten sollten. Sie können den Anforderungen großer hybrider Belegschaften mit unterschiedlichen Aufgaben auf verschiedenen Geräten in verschiedenen Zuständen einfach nicht gerecht werden. (U)ZTNA bietet präzisen Zugriff, der sich an Rollen, Geräte und Zustände anpassen lässt. Beachten Sie auch, dass (U)ZTNA die schlimmste Art von privilegiertem Server eliminiert: einen VPN-Konzentratoren, der (zunehmend erfolglos) versucht, eine Brücke zwischen dem Internet und einem privilegierten Netzwerk zu schlagen, indem sie sich auf einen harmlosen Listening-Socket verlassen, der den Unwägbarkeiten des unsicheren Internets ausgesetzt ist.
- Verringert den Bedarf an NAC, da der Fokus auf den Zugriff auf Anwendungsebene anstatt auf Netzwerkebene liegt. Die IP-basierte Weiterleitung zwischen den Geräten der Benutzer und ihren Zielen findet nicht mehr statt, und es existieren keine Pfade zu Switch-Ports oder anderen Aspekten der Netzwerkinfrastruktur. Die bloße Zugehörigkeit zu einem Netzwerk bietet keinen Vorteil mehr, wenn man nicht zufällig mit den dort vorhandenen Inhalten interagieren kann. Außerdem scheitern viele NAC-Projekte, weil die Hardware veraltet ist, Ausfallzeiten nicht toleriert werden können, Richtlinien wild wuchern und die vielen beweglichen Teile nicht immer gut ineinandergreifen. NAC zeugt noch immer von einem impliziten Vertrauensmodell (man kann sich nach dem Beitritt zum Netzwerk überallhin bewegen), was das Gegenteil von gängigen modernen Sicherheitsprojekten ist, die auf Zero-Trust-Strategien basieren.
- Bietet einen optimierten standortbasierten Zugriff, ohne langsame Umwege oder andere Hindernisse, die Nutzer zu unsicheren Ausweichlösungen zwingen könnten. Harmonisierter Zugriff verhindert, dass Menschen schlechte Sicherheitsvorkehrungen umgehen. Optimierter Zugriff verhindert, dass Menschen schlechte Leistung umgehen. Wenn die Mitarbeiter sofort auf das zugreifen können, was sie brauchen, ohne zu basteln oder auf Hacks zurückzugreifen oder überhaupt darüber nachzudenken, was zu tun ist, je nachdem, wo sie sich gerade befinden, bleiben sie maximal produktiv und bei guter Laune (und halten die Telefonleitungen des Helpdesks offen).
Im Grunde hebt Universal ZTNA alle Unterschiede zwischen lokal und remote auf. Jetzt geht es nur noch um den Zugang – maßgeschneidert, konsistent, schnell und sicher. Gestalten Sie Ihre Zugriffsarchitektur jetzt neu – mit dem Universal ZTNA von Netskope. Danke fürs Lesen.
Mark Fabbi (ein weiterer ehemaliger Gartner-Analyst und jetzt Berater für den CXO von Netskope) und ich haben ein Webinar aufgenommen, in dem wir die Vorteile Universal ZTNA weiter beleuchten. Jetzt ansehen.

Den Blog lesen